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[57] ABSTRACT 

An online commerce system facilitates online commerce 
over a public network using an online commerce card. The 



"card" docs not exist in physical form, but instead exists in 
digital form. The online commerce card is issued electroni- 
cally to a customer by an issuing institution. Hie issued card 
is assigned a permanent customer account number thai is 
maintained on behalf of the customer at the issuing institu- 
tion to remove the risk of the number being lost or s stolen. 
When the customer desires to conduct an online transaction, 
the customer asks the issuing institution to issue a transac- 
tion number for a single transaction. The issuing institution 
generates a temporary transaction number and associates it 
with the permanent account number in a data record. The 
customer receives the transaction number and submits that 
number lo the merchant as a proxy for the customer account 
number. The transaction number looks like a real card 
number and the merchant handles the transaction number in 
the same manner as any regular credit card number. When 
the merchant submits an request for authorization, the issu- 
ing institution recognizes the number as a transaction num- 
ber for an online commerce card. The issuing institution 
references the customer account number, using the transac- 
tion number as an index, and processes the authorization 
request using the real customer account number in place of 
the proxy number. Once the authorization request is 
processed, the issuing institution once again exchanges the 
transaction number for the customer account number and 
sends an authorization reply back to the merchant under the 
transaction number. 

45 Claims, 5 Drawing Sheets 
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ELECTRONIC ONLINE COMMERCE CARD 
WITH TRANSACTIONPROXY NUMBER FOR 
ONLINE TRANSACTIONS 

TCCHNICAL FIELD 

This invention relates to systems and methods for facili- 
tating online commerce over a public network (such as the 
Internet or an Interactive TV/Cable Network) using credit 
cards, debit cards, and other types of financial/banking 
cards. More particularly, this invention relates to systems 
and methods for conducting online transactions using an 
electronically realizable card that has a private, permanent 
account number maintained on behalf of a customer by an 
issuing institution and temporary transaction numbers issued 
to the customer on a transactional basis without exposure of 
the permanent account number. 

BACKGROUND OF THE INVENTION 

Online commerce is experiencing dramatic growth in 
recent years. More merchants are developing sites on the 
World Wide Web (or simply "WWW" or "Web") that 
consumers can access and order goods and/or services. It is 
fairly common for a consumer to browse a merchant's 
catalog, select a product, place an order for the product, and 
pay for the product all electronicaUy over the Internet. 

Typically, the consumer pays for the goods and/or ser- 
vices ordered over the Internet with a credit card. During the 
online U'ansaction, the merchant sends an order form and 
requests the consumer to enter personal data (e.g., name, 
address, and telephone number) and credit card information 
(e.g., account number and expiration date). The consumer 
returns the completed order form containing the credit card 
information to the merchant over the Internet. The merchant 
verifies that the credit card number is valid and can be 
charged the payment amount. The card verification is usu- 
ally conducted on a well-established card network, such as 
the VisaNet® network or the Veriphone® network. 

One problem with this traditional online commerce model 
concerns the security of the credit card data as it travels over 
the Internet. The credit card information can be intercepted 
in route, copied into a database, and used to make unautho- 
rized purchases. In an automated environment, an imposier 
can repeatedly use the stolen credit card data to conduct 
many online transactions before the consumer ever becomes 
aware that the credit card data has been stolen. 

It would be desirable to develop a new online commerce 
model that reduces or eliminates the incentive for stealing 
credit card data. Ideally, a secure online commerce model 
would render the credit card data hard to steal, and if stolen, 
worthless to the thief. 

Another concern is that any new online commerce model 
should integrate well with existing proprietary card network 
systems. There are well-established systems that verify 
credit card purchases and subsequently settle accounts. 
These systems and associated protocols are entrenched in 
the merchant and banking communities and experience a 
high level of acceptance and trust. A new online commerce 
model should not usurp these systems, nor require mer- 
chants to change their existing practices to implement com- 
pletely different systems and protocols. 

The inventor has developed a card-based online com- 
merce system that improves security and integrates with 
existing card verification and settlement systems. 

SUMMARY OF THE INVENTION 

This invention concerns a system and method for facili- 
tating online commerce over a public network (such as the 
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Internet or Interactive TV/Cable Network) using an online 
commerce card. The "card" of this system does not exist in 
physical form, but instead exists in a digital form that can be 
electronically realized for online commerce, 

5 The online commerce card is issued electronically to a 
customer by an issuing institution, such as a bank or third 
party certifying authority. The issued card is assigned a 
permanent customer accotmt number that is maintained on 
behalf of the customer by the issuing institution. The cus- 

10 tomer account number is not given to the customer to 
remove the risk of that number being lost or stolen. 

When the customer desires to conduct an online 
transaction, the customer sends a request to the issuing 
institution to issue a transaaion number for a single trans- 
action. The issuing institution generates a temporary trans- 
action number and associates it with the pennanent account 
nmnber in a data record. The customer receives the trans- 
action number and submits that number to the merchant as 
a proxy for the customer account number during the trans- 

^ action. 

The transaction number looks like a real card number (i.e., 
it has the same format and number of digits as a regular 
credit card). To the merchant, the transaction number is 
treated the same as any regular credit card number. The 

^ merchant handles the proxy transaction number according to 
traditional protocols, including seeking authorization from 
the issuing institution to honor the card number. 

During the authorization phase, the issuing institution 
recognizes the number as a transaction number for an onhne 
commerce card. The issuing institution references the cus- 
tomer account number associated with the online commerce 
card, using the transaction number as an index to the 
appropriate data record, and processes the authorization 
request using the card's true customer account number. In 
this manner, the issuing institution can use its existing 
processing system to check account information, spending 
limits, and so forth. Once the authorization request is 
processed, the issuing institution once again exchanges the 
card's transaction number for the card's customer account 
number and sends an authorization reply back to the mer- 
chant under the transaction number. 

As a result, the merchant never needs to know if the 
number is a legitimate account number, or a proxy number 

45 for an account number. The merchant does not need to 
implement any new devices, software, or protocols to par- 
ticipate in the new online commerce system. 

For added security, the transaction number can be linked 
to extra transaction information to ensure that the number is 

50 only used for one specific transaction. For instance, the 
issuing institution might tie the transaction number to a 
specific purchase amount and a particular merchant ID. The 
issuing institution might further impose a short expiration 
term on the U'ansaction number so that the number becomes 

55 invalid after the expiration term lapses. 

The online commerce system substantially reduces the 
value of a stolen number since the transaction number that 
is transmitted over the Interact (or other network) is only a 
proxy number for a single purchase. Stealing the proxy 

60 number would not greatly benefit a thief because it cannot be 
repeatedly used for other purchases or transactions. In 
addition, the system seamlessly integrates with existing card 
verification and settlement protocols. Software modules are 
implemented at the customer and issuing institution, but no 

55 additional components are implemented at the merchant, 
settlement participants, or any other member in the online 
commerce transaction. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The same reference numbers are used throughout the 
figures to reference like compouents and features. 

FIG. 1 is diagrammatic illustration of an online commerce 
system. 

FIG. 2 is a block diagram of a customer computing unit 
and bank computing center. FIG. 2 shows an information 
exchange between the customer computing unit and the 
bank computing center during an online commerce card 
registration phase. 

FIG. 3 is the same as FIG. 2, but shows an information 
exchange between ibe customer computing unit and the 
bank computing center during a transaction request phase. 

FIG. 4 is a diagrammatic illustration of data records 
maintained at the bank computing center to associate a 
permanent customer account number to a temporary trans- 
action number used in an online commerce transaaion. 

FIG. 5 is a block diagram of the bank computing center 
and a merchant computing unit. FIG. 5 shows an informa- 
tion exchange between the merchant computing unit and the 
bank computing center during a payment authorization 
phase. 

DETAILED DESCRIPTION 

The following discussion assumes that the reader is 
familiar with cryptography. For a basic introduction of 
cryptography, the reader is directed to a text written by 
Bruce Schncicr and entitled "Applied Cryptography: 
Protocols, Algorithms, and Source Code in C," published by 
John Wiley & Sons with copyright 1994 (with a second 
edition in 1996), which is hereby incorporated by reference. 

FIG. 1 shows an online commerce system 20 for con- 
ducting online commerce transactions. For general discus- 
sion purposes, three participants to an online commerce 
transaction are shown: a customer 22, a merchant 24, and an 
issuing bank 26. These three participants play the primary 
roles in the online commerce transaction. The customer and 
merchant may represent individual people, entities, or busi- 
nesses. Although labeled as a "bank", the issuing bank 26 
may represent other types of card-issuing institutions, such 
as credit card companies, card sponsoring companies, or 
third party issuers under contract with financial institutions. 
It is flinher noted that other participants may be involved in 
some phases of the transaction, such as an intermediary 
settlement institution, but these participants are not shown. 

Each participant is equipped with a computing system to 
facilitate online commerce transactions. The customer 22 
has a computing unit 28 in the form of a personal computer, 
although other types of computing units may be used 
including laptops, notebooks, handheld computers, set-top 
boxes, and the like. The merchant 24 has a computing unit 
30 implemented in the form of a computer server, although 
other implementations are possible. The bank 26 has a 
computing center 32 shown as a mainframe computer 
However, the bank computing center 32 may be imple- 
mented in other forms, such as a minicomputer, a PC server, 
a networked set of computers, and the like. 

The computing units 2S, 30, and 32 are connected with 
each other via a data communication network 34. The 
network 34 is a public network and assumed to be insecure 
and open to eavesdroppers. In the illustrated 
implementation, the network is embodied as the Interact. In 
this context, the computers may or may not be connected to 
the Internet 34 at all times. For instance, the customer 
computer 28 may employ a modem to occasionally connect 
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to the Internet 34, whereas the bank computing center 32 
might maintain a permanent connection to the Internet 34. It 
is noted that the network 34 may be implemented as other 
types of networks, such as an interactive television (ITV) 
network. 

The merchant computer 30 and the bank computer 32 are 
interconnected via a second network, referred to as a "pay- 
ment netii^'ork" 36. The payment network 36 represents 
existing proprietary networks that presently accommodate 
transactions for credit cards, debit cards, and other types of 
financial/banking cards. The payment network 36 is closed 
network that is assumed to be secure firom eavesdroppers. 
Examples of the payment network 36 inchide the \^aNet® 
network and the Veriphone® network. 

Tlie electronic commerce system 20 is implemented at the 
customer 22 and issuing bank 26. In the preferred 
implementation, the electronic commerce system 20 is 
implemented as computer software modules loaded onto the 
customer computer 28 and the bank computing center 32. 
The merchant computer 30 does not require any additional 
software to participate in the online commerce transaction 
supported by the online commerce system 20. 
General Operation 

There are three distinct phases supported by the online 
commerce system 20: a registration phase, a transaction 
phase, and a payment authorization phase. During the reg- 
istration phase, the customer 22 requests an online com- 
merce card from the issuing bank 26. The issuing bank 26 
creates an online commerce card for the customer and 
assigns a permanent customer account number to the card. 
The permanent customer account number is retained in a 
data record at the issuing bank 26 and not given to the 
customer 22. This prevents the customer accoimt number 
from being stolen while being transferred over the Internet 
34 or stored on the customer's computer 28. 

The "online commerce card" does not exist in physical 
form, but in digital form for use in online transactions. The 
issuing bank 26 issues the card to the customer 22 in the 
form of a signed digital certificate binding the customer to 
the bank and a software module that can be invoked when 
using the commerce card to conduct a transaction on the 
Internet 34, The commerce card is configured to be used by 
the customer in one or more areas of commerce in which the 
customer typically employs a credit card, a debit card, a 
bank card, or other type of financial services card. The 
registration phase is described below in more detail with 
reference to FIG. 2. 

During the transaction phase, the customer 22 invokes the 
software module, which submits a request for a secure card 
number to the issuing bank 26. The issuing bank generates 
a random temporary transaction number and associates the 
transaction number with the permanent customer account 
number in a data record. The issuing bank 26 issues the 
transaction number to the customer to use as a proxy for the 
real customer account number. The transaction number 
resembles a real account number. In the case of a credit card, 
for example, the transaction number and real customer 
account number are both I6-digit, mod 10, numbers iden- 
tically formatted with four spaced sets of 4-digits. To the 
customer (and every other participant in the transaction), the 
transaction number appears to be a valid credit card number. 
Only the issuing bank 26 differentiates the transaction 
numbers fi'om the real customer account numbers. The 
customer 22 uses the proxy transaction number in the 
transaction with the merchant 24. Since the transaction 
number is issued in place of the customer number for only 
a single transaction and with a limited life, a thief that 
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intercepts the transaction number is prevented from using it The bank computer 32 has an account manager 60. a 

for illicit gain. The transaction phase is described below in transaction number generator 62 and a customer database 

more detail with reference to FIG. 3. 64. The account manager 60 and transaction number gen- 

During the payment authorization phase, the merchant 24 erator 62 are preferably implemented in software that 

submits the transaction number over the conventional pay- 5 executes on the bank computer 32. The transaction number 

menl network 36 to the issuing bank 26 for approval. The generator 62 is preferably a random number generator that 

issuing baok 26 identifies the number as a transaction creates random numbers in the same formal as the customer 

number, as opposed to a real customer account number. The ^^^^^ ^^^^i,^^ software modules 60 and 62 may be 

issumg bank 26 uses the transaciion number to retrieve the executed individually or integrated into the same software 

data record Lnking the transaction nunibcr to a customer program, such as a relational database program thai manages 

account Dumber. The issumg bank 26 then swaps the cus- (he relational database 64 

tomer account number for the transaction number and pro- . ^ . . u ^ .u . j ■ * 

cesses the authorization request using its conventional pro- ^ registration phase between the customer and issumg 

cessiDg system. After the processing, the issuing bank 26 bank wiU now be descnbed wiUi respect to FIG. 2. Dunng 

substitutes the transaciion number back for the customer operation on the Web. the customer comes across a 

account number and returns the authorization reply to the 15 banner advertising an onlme commerce card sponsored by 

merchant 24 under the transaction number, lo this manner, the issuing bank. The banner may be part of the bank's Web 

only the issuing bank is aware that the transaaion number is site, or part of a statement to its customers, or included as 

a proxy for the customer account number. The merchant 24 advertisement in other Web content. The customer activates 

need not be aware that the transaction number is not a true the banner by clicking the banner icon with a mouse pointer, 

customer account number, but simply handles the number as 20 This action submits a request for an online commerce card 

it would any other card number. The authorization phase is apphcation. In response, the customer downloads the regis- 

described below in more detail with reference to FIG. 5. tration module 56 from the Web to the customer computer 

Registration Phase 28. This initial registration step is illustrated by flow arrow 

FIG. 2 shows the online commerce system 20 during a 1 from the Internet 34 to the customer computer 28. 

registration phase. This phase involves the customer 22 25 The registration module 56 automatically launches lo aid 

requesting an online commerce card from the issuing bank the customer in the completion of the online application. The 

26, and the issuing bank creating and issuing the online registration module is preferably configured to provide 

commerce card to the customer. The information exchange step-by-step instructions, such as a Help Wizard. Tlie cus- 

beiween the customer computer 28 and the bank computer tomer fills out various fields related to personal and financial 

32 during the registration phase are illustrated as enumerated 30 matters, such as name, address, telephone number, social 

lines between the two entities. security number, presently owned credit cards, bank 

The customer computer 28 has a central processing unit affiliations, and the like, 

comprising a processor 40, a volatile memory 42 (e.g.. The customer completes the online commerce card appli- 

RAM), and a non-volatile memory 44 (e.g.. ROM, hard disk cation using the registration wizard and submits the appli- 

drive. floppy disk drive, CD-ROM. etc.). The customer 35 cation to the issuing bank (flow arrow 2 in FIG. 2). The 

computer 28 also has a network I/O 46 (input/output) for registration module 56 facilitates this communication and all 

accessing the Internet 34, The network I/O 46 can be future interaction between the consumer and the issuing 

implemented, for example, as a dial-up modem or as a bank. The application itself, or the registration module 56, 

permanent network connection. contains the necessary routing information to direct the 

The customer computer 28 runs an operating system 48 40 application over the Internet 34 to the bank computing 
that supports multiple applications. The operating system 76 center 32. The issuing bank reviews the application to 
is preferably a multitasking operating system that allows determine whether the customer is credit worthy 19 and 
simultaneous execution of multiple applications in a graphi- pending the analysis, whether to grant or deny a commerce 
cal windowing environment. One preferred operating sys- card. If a new card is denied, the issuing bank returns a 
tem is a Windows® brand operating system sold by 45 message to the customer indicating that the card application 
Microsoft Corporation, such as Windows® 95, Windows® has been denied and no card wiU be issued. Conversely, if a 
NT, Windows® CE, or other derivative versions of Win- new card is to be granted, the issuing bank returns a message 
dows®. It is noted, however, that other operating systems indicating that a card will be granted assuming the remain- 
that provide windowing environments may be employed, ing registration steps are satisfied. 

such as the Macintosh operating system from Apple 50 Assuming that a card account is granted, the issuing bank 

Computer, Inc. creates a temporary customer account record in the customer 

The operating system 48 includes a certificate store 50 lo database 64 and assigns a temporary PIN (personal identi- 

securely hold digital certificates. The certificate store 50 fication number) or other type of customer identifier to that 

holds a signed certificate received from the issuing bank as account. The bank supplies the PIN and any additional 

part of the onhne commerce card. 55 software needed to complete the formal application process 

Several software components are stored in memory 42 to the customer. In the preferred implementation, the bank 

including a browser 52, a button user interface (UI) 54, and supplies the PIN and software using some means other than 

a registration module 56. These software components load online transmission. FIG. 2 shows the PIN and software 

into volatile memory when launched and execute on the being stored on a floppy disk 68 and mailed to the customer 

processor 40 atop the operating system 48. The browser 60 using conventional postal carriers (flow arrow 3 in FIG. 2). 

software 52 originally exists on the customer computer 28, Using regular mail provides an added level of security in 

whereas the button Ul 54 and registration module 56 are that the bank can verify through the mailing address that a 

downloaded lo the customer computer 28 during the regis- customer having the registered name and address truly lives 

iraliou process. U is further noted that the but loo UI 54 may at the place inscribed on the online registration form. This 

be integrated into, or rely on, the graphical user interfaces 65 increases the bank's confidence that the customer did not 

supported by the operating system 48, but is shown sepa- submit a fraudulent application. Another benefit is that the 

rately for explanation purposes. software on floppy disk 68 might contain cryptographic 
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modules to secure communication between the customer and (and/or toolbars of other applications). The button Ul 54 

issuing bank. Providing the cryptography on a disk that is enables the customer to invoke the wizard to communicate 

mailed to a U.S. address avoids the problem of unknowingly with the issuing bank during future commerce transactions, 

supplying cryptographic code to foreigners in a manner At this point, the customer has been issued an "online 

contrary to U.S. export laws. 5 commerce card". 

The customer receives a PIN mailer three to ten days The registration process is described as an interaction 

following application submittal. Upon receiving the PIN, the between the customer and an issuing bank. It is noted that a 

customer invokes the registration module 56 and prepares a third party may handle some or all of the registration tasks 

"request for a certificate" from the issuing bank. As part of on behalf of the bank. Such third parties are often referred 

creating the request for certificate, the customer is asked to lo to as "certifying authorities", "credential binders," "binding 

enter a public key (or one can be provided automatically by autboriiies," or simply "binders." However, for discussion 

the customer computer). The registration wizard 56 gener- purposes, the issuing bank is assumed to perform all of the 

ates an associated private key using its own resources, or by functions of a bank and an issuing institution, 

calling a cryptographic services library resident on the Transaction Phase 

customer computer. The cryptographic services perform 15 FIG. 3 shows the online commerce system 20 during a 

such tasks as encryption, decryption, digital signing, transaction phase. This phase involves the customer 22 

authentication, and hash computations. engaging in an online commerce transaction with the mer- 

Tbe pair of public and private keys is unique to the chant 24. As part of the process, the customer 22 requests a 

customer. The public/private keys form the foundation of transaction number from the bank 26 to be used in the 

public cryptography systems and are based upon a math- 20 commerce transaction. The information exchange between 

ematical relationship in which one key cannot be calculated the customer computer 28, the merchant computer 30, and 

(at least in any reasonable amount of time) from the other the bank computer 32 during the transaction phase are 

key. The holder distributes the public key to other parties and illustrated as enumerated lines. 

maintains the private key in confidence. Public key cryp- The customer invokes the browser 52 to surf the Web for 

lography is well known. An example of an asymmetric 25 a particular product or service, or to visit a Web site of a 

cipher is the well-known RSA cryptographic algorithm particular merchant. Suppose that the customer decides to 

named for the creators Rivest, Shamir, and Adleman. commence an online u-ansaction with the merchant, such as 

The customer computer 28 submits the certificate request purchasing a product from the merchant. The customer 

to the issuing bank (flow arrow 4 in FIG. 2). The certificate downloads an order form 70 from the Web and stores it in 

request contains the public/private key pair and the tempo- 30 volatile memory 44 (flow arrow 1 in FIG. 3). The order form 

rary PIN, which serves as a baseline authentication of the 70 is typically configured as an HTML (hypertext markup 

customer requesting the certificate. language) form. The customer fills out the order form 70 to 

If the bank still desires to grant an online commerce card purchase a desired product from the merchant. The order 

to the customer, the account manager 60 at the issuing bank form 70 includes a payment section that requires the cus- 

converts the temporary customer account record to a per- 35 tomer to enter a credit card number for payment of the 

manent account record in the database 64. The bank's goods. 

account manager 60 assigns a permanent customer account Upon reaching this method of payment field, the customer 

number to the customer account record. clicks the card button UI 54 on the browser toolbar to invoke 

The customer account number uniquely associates all a card transaction module 72. The transaction module 72 is 

relevant database records to a specific customer. The cus- 40 the wizard software created as a result of the registration 

tomer account number may exist in many diflerent forms, process of FIG. 2 and is employed to guide the customer 

For instance, if the customer already possesses a real credit through a request for a transaction number 

card or debit card from the bank, the number from the credit Upon clicking the button Ul 54, a dialog box appears on 

card or debit card is the customer account number used to the display to inform the customer that they have requested 

identify the data record for the online commerce card. In this 4S a secure card number. The customer is prompted by the 

manner, the customer can use the digital online commerce dialog box to input a password for identification purposes, 

card concurrently with the physical credit or debit card. As This password might be the private key (if the customer 

another implementation, the public key, private key, or a knows the key value) or it may be a separate name or number 

mathematical derivation of one or both keys (e.g., a hash created by the customer. The operating system 48 checks the 

value of one or both keys) might be employed to represent 50 password prior to allowing access to the certificate store 50. 

the customer account number. Another alternative is for the If the password is approved, the transaction module 72 

bank to generate an internal number that is used for solely prepares a request for a transaction number, digitally signs 

for record keeping purposes. the request using the customer's private key, and submits the 

The issuing bank digitally signs a certificate containing signed request to the issuing bank's computer 32 via the 

the public/private key pair and places the customer's public 55 Internet 34 (flow arrow 2 in FIG. 3). The request contains the 

key in the customer account record in the database 64. One certificate originally issued by the bank, 

technique for forming this digital signature is lo hash the The bank computer 32 receives the signed request and 

certificate and encrypt the resulting hash value using the immediately verifies the identity and authenticity of the 

bank's private signing key. The issuing bank returns the customer by applying the customer's public key to the 

signed certificate to the customer via the Internet 34 (flow 60 digital signature and examining the certificate. Assuming the 

arrow 5 in FIG. 2). signature and request are valid and the customer's account 

The certificate is deposited in the certificate store 50 on is in good standing, the account manager 60 instructs the 

the customer computer 28. The certificate and customer's transaction number generator 62 lo create a transaction 

private key act as a password for all future authenticated number to be used as a proxy for the customer account 

conversations between customer and issuing bank. Along 55 number during the online commerce transaction. The 

with the certificate, the issuing bank also downloads the account manager 60 associates the transaction number with 

button UI 54, which can be added to the browser's toolbar the customer account number in a data record on the 
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customer database 64. As a result, the online commerce card 
DOW has two numbers associated therewith: a permanent 
customer account number and a transaction number that 
serves as a proxy for the customer account number. 

FIG. 4 shows one exemplary implementation of creating 
a transaction number and associating that number with the 
customer's account number. A customer record 80 for the 
requesting customer is stored in the customer database 64 
and contains a customer account number. Suppose, for 
example, the customer account number is a 16-digit credit 
card number. Credit card numbers comply with a standard- 
ized format having four spaced sets of numbers, as repre- 
sented by the number "0000 0000 0000 0000". The first 
five-lo-scvcn digits are reserved for processing purposes. It 
identifies the issuing bank, the card type, and so forth. The 
last 16''' digit is used as a sum check for the 16-digit number. 
The intermediary eight-toten digits are used to uniquely 
identify the customer. 

The transaction number generator 62 generates a trans- 
actioD number for the online commerce card that is format- 
ted identically to the customer account number. In this 
example, the number generator 62 creates a 16-digit trans- 
action number having four ^aced sets of numbers, as 
represented by the number "lUl 1111 1111 HIT*. The 
transaction number resembles a credit card number in all 
respects, except that the first five-seven-digits are coded by 
the issuing bank to identify the number as a fictitious 
electronic proxy number, rather than a real credit card 
number 

Tlie account manager 60 associates the temporary trans- 
action number with the permanent customer account number 
by relating the two numbers in a data record 82. More 
particularly, the account manager creates data record 82 in a 
proxy/customer account cross-reference database. The data 
record 82 is keyed with the customer account number to 
identify the customer record 80. The transaction number is 
then written to the data record 82. In this manner, the 
customer account record 80 can be cross-referenced via the 
transaction record 82 using the transaction number as an 
index. The issuing bank will use the transaction record 82 at 
a later time when the merchant submits the transaction 
number for payment authorization. 

The transaction number is designed to have a finite life, as 
determined by the issuing bank. The shorter the duration, the 
less likelihood of fraud resulting from the transaction num- 
ber being stolen and reused prior to the end of its life. The 
chief requirement of the expiration term is that it be suffi- 
ciently greater than the anticipated worst case time for 
returning the authorization request response to the merchant, 
plus overhead to account for customer and merchant han- 
dling prior to submittal of the authorization request. The 
networks operated by Visa and MasterCard allegedly handle 
submission and return of an authorization request (round trip 
from the merchant to the issuing bank and back to the 
merchant) in less than four seconds, which is essentially 
negligible compared to the time reserved for customer and 
merchant handling. Accordingly, a suitable expiration term 
for a transaction number can be one-half hour to two hours. 
In FIG. 4, the account manager 60 assigns an expiration term 
of one hour to the transaction number in record 82. When the 
expiration term lapses, the transaction number is no longer 
valid. 

The transaction number is valid for only one transaction. 
For added security, the transaction number can be linked to 
transaction information to ensure that the number is only 
used for one specific transaction. The transaction module 72 
executing on the customer computer 28 may require the 
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customer to enter information pertaining to the purchase, 
like the purchase price, the model or item number, the 
merchant name, and the like. The issuing bank can then tie 
the transaction number to this specific transaction data 

s within the transaction record 82. 

Once the transaction record 82 is created and related to the 
customer record 80, the issuing bank computer 32 sends the 
transaction number to the customer computer 28 (Sow arrow 
3 in FIG. 3). The real customer account number is not sent 

10 to the customer, but is retained at the issuing bank in secrecy. 
In the credit card case, this means that the true credit card 
number is never sent over the Internet 34, thereby eliminat- 
ing the possibility of interception and illicit use by a thief. 
At the customer computer, the transaction number is 

15 presented in a graphical window by the transaction module 
72. If the order form is compatible, the customer can click 
on an icon to have the number automatically entered into the 
merchant order form 70. Otherwise, in a worst case scenario, 
the customer manually enters the proxy transaction number 

20 into the merchant's HTML order form 70. Since the trans- 
action number has the identical 16-digit format as a real 
credit card number, the customer enters the 16-digit number 
as if it were his/her real credit card number. 
The user may also be required to enter an expiration date, 

25 which may or may not be sent from the issuing bank. 
Essentially, the expiration date can be any future date that is 
not too far in the distant future, such as less than two to three 
years. The customer then submits the completed order form 
70 over the Internet 34 to the merchant computer 30. 

30 Authorization Phase 

FIG. 5 shows the online commerce system 20 during a 
payment authorization phase. This phase involves the mer- 
chant 24 seeking authorization from the issuing bank 26 to 
honor the customer's transaction number received by the 

35 merchant in the commerce transaction with the customer. 
The information exchange between the merchant computer 
30 and the bank computer 32 during the authorization phase 
are illustrated as enumerated lines. 
The merchant 30 receives the transaction number from the 

40 Internet and processes the transaction number using its 
existing computer system. There is no software components 
added to the merchant computer as part of the online 
commerce system 20. Rather, the merchant computer 30 
treats the transaction number of the online commerce card 

45 no differently than it treats a standard credit card number. In 
fact, the merchant computer 30 most likely will not be able 
to distinguish between the two types of numbers. 

In FIG. 5, the merchant computer submits a request for 
authorization over a payment network 36 to the bank com- 

50 puting center 32 (flow arrow 1 in FIG. 5). This illustration 
is simplified for discussion purposes, as other participants 
will most likely be involved. For instance, the merchant 
computer 30 typically submits the request for authorization 
to its acquiring bank (not shown) by conventional means, 

55 The acquiring bank validates the authorization request by 
verifying that the merchant is a valid merchant and that the 
credit card number represents a valid number. The acquiring 
bank then forwards the authorization request to the issuing 
bank. The routing to the issuing bank via the payment 

60 network is handled through conventional techniques. 

When the bank computer 32 receives the authorization 
request, it first examines the transaction number to deter- 
mine whether it is a valid number. A transaction number 
identifier 90 executing at the bank computer 32 examines all 

65 incoming account numbers to segregate proxy transaction 
numbers fi^om real credit card numbers. On a daily basis, it 
is likely for the bank computer 32 to handle many account 
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numbers on the order of tens or hundreds of thousands. Most When the settlement file references a transaction number, 

of the numbers are expected to be real credit card account however, the account manager 60 performs essentially the 

numbers. Only a small percentage is anticipated to be same lookup-and^ubstituie process described above with 

temporary transaction numbers. The transaction number respect to the authorization request. That is, the account 

identifier 90 filters out authorization requests that pertain to 5 manager fetches the customer account number fi-om the 

transaction numbers from authorization request that pertain cross-referenced records 80, 82 in the database 64. replaces 

to real customer account numbers. In the continuing transaction number in the batch with the customer 

example, the transaction number identifier 90 recognizes the processes the batch using conventional 

number submitted by the merchant computer 30 as a trans- ,. . , ^ 

action number based on >he firs, five-lo-seven digits. ,o ""'•"" ^on^'^i^e system has many advantages One 

™_ . I. J . c nn .u . advantage is that It substantially reduces the value of a stolen 
_ ine transaction numt^r taentmer vo passes ine iransac Q^bersince the number is only a proxv number for a single 
tion number to the account manager 60. The account man- p^^^hase. SteaUng the proxy number would not greaUy 
ager 60 uses the transaction number as an index to transac- ^^^^^^ ^ t^icf because it cannot be repeatedly used for other 
tion records in the customer database 64. If no records are purchases or transactions. Another benefit is that the system 
found, the number is deemed invalid and the bank computer 15 integrates with existing card verification and settlement 
32 returns a message disapproving the transaction to the protocols. All parties, except the issuing bank, are able to 
merchant computer 30. If a record is found, the account treat the transaction number of the online commerce card in 
manager 60 examines any extra transaction information, the same manner in which they process a Visa® or Master- 
such as purchase amount and merchant ID, which is typi- Card® transaction today. No additional processing software 
cally included in the authorization request to double check 20 is needed at the merchants or settlement participants, 
the accuracy of the request. Although the invention has been described in language 

Once a valid transaction record 82 is located, the account specific to structural features and/or methodological steps, it 

manager 60 cross-references to the associated customer is to be understood that the invention defined in the 

account number and uses this number to index the customer appended claims is not necessarily limited to the specific 

record 80. The account manager 60 substiuites the customer 25 Matures or steps described. Rather, the specific features and 

account number in place of the u-ansaction number in the s^^PS are disclosed as preferred forms of implementing the 

merchant authorization request. The account manager 60 claimed mvention. 

then submits the authorization request to the bank's tradi- ^ * jc r v. i- 

tional processing system 92 for normal authorization pro- J i^iZt facditatmg onhne commerce, comprtsmg 

cessing (e.g., confirm account status, credit rating, credit 30 . , ^ , . 

line etc ) issumg an electromc commerce card to a customer dunng 

After the request is processed, the processing system 92 " registration phase, the commerce card having a per- 

relurns an authorization response to the account manager 60. """J*' associated thetewilh to identify the 

The account manager fetches the transaction number from customer, an 

the cross-referenced data records 80 and 82 in the database 35 ^^^^S ^^^^ commerce transaction phase, issuuig a 

64 and substitutes the transaction number in place of the P^^^ ^^^^^^ ^^^^ ^ associated with the permanent 

customer account number in the bank^s authorization reply. number for use in an onhne commerce transaction m 

The bank computing center 32 then returns the authorization P^^^ ^f the permanent number on the commerce card, 

reply to the merchant computer 30 via the payment network 2. A method as recited in claim 1, wherein the issuing 

36 (flow arrow 2 in FIG. 5). 40 ^^^P^ comprise issuing permanent and proxy numbers that 

-nie preceding steps assume the authorization request was formatted with an equal number of digits, 

successful. If that is the case, the credit limit of the custom- ^- ^ method as recited m claim 1, wherem the issuing 

er's account is drawn down in the amount of the steps are performed onUne. 

authorization, and the transaction is logged for future post- 4. A method as recited in claim 1, wherein the step of 

jjjg 45 issuing the commerce card comprises the step of supplying 

Settlement customer a signed digital certificate and software code 

During settlement, batches of transactions are submitted »*iat supports a user interface button that invokes a user 

to a card association, which performs the following opera- i^^^^i^cc for requesting the proxy number. 

j^-Qj^. 5. A method as recited in claim 1, wherein the step of 

Edit/balance the batch transactions 50 ^^"'"8 the proxy number comprises the step of i^uing a 

proxy number havmg a finite period ot time withm which the 

aiculate the mterchange fees p^^^y ^^^^^^ be used. 

Verify the fees 5 ^ method as recited in claim 1, further comprising the 

Route chargeback transactions step of using the proxy number during the online commerce 

Calculate net settlement 55 transaction. 

Distribute interchange files to the issuers 7. A method as recited in claim 1, wherein prior to the step 

Transmit settlement advisements to the clearing (issuer) of issuing an electronic commerce card, the method corn- 
banks prises the following additional steps: 

Transmit settlement to the settlement (card association) initiating, from the customer, a request for ibe commerce 

b^jjj^ 6Q card from an issuing authority; and 

The issuing bank receives a daily interchange file that downloading software code to the customer to assist in a 

contains all transactions submitted by merchants against card registration process. 

customer accounts owned by the issuing bank for that day. 8- A method as recited in claim 1, wherein prior to the step 

In addition, the issuing bank also receives other settlement of issuing an electronic commerce card, the method com- 

transactions such as chargebacks, retrieval requests, 65 prises the following additional steps: 

re-present menls, etc. The settlement process thus far is initiating, from the customer, a request for the commerce 

conventional. card from an issuing authority; 
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suppi>iag a preliminary identifier to the customer; and 
using the preliminary identifier to request a certificate 

from the issuing authority, the certificate being part of 

the commerce card. 

9. A method as recited in claim 8, wherein the step of 
issuing the commerce card comprises the step of supplying 
to the customer a signed digital certificate and software code 
that supports a user interface button that invokes a user 
interface for requesting the proxy number. 

10. A graphical user interface embodied on a computer- 
readable medium that presents the user interface button as 
recited in claim 9. 

11. An electronic commerce card embodiment on a 
computer-readable medium that is created as a result of the 
steps in the method as recited in claim 1. 

12. A computer-readable medium having computer- 
executable instructions for performing the steps in the 
method as recited in claim 1. 

13. A computer programmed to perform the steps in the 
method as recited in claim 1. 

14. A method for registering for an online commerce card, 
comprising the following steps: 

initiating, at the customer, a request for an online com- 
merce card application; 

downloading software code to the customer to assist in 
completing the card application; 

submitting the application for the commerce card from the 
customer to the issuing authority; supplying a prelimi- 
nary customer identifier to the customer; 

submitting a request for a certificate from the issuing 
authority, the request including the preliminary cus- 
tomer identifier to identify the customer; 

associating a customer account number with the cus- 
tomer; and 

downloading a signed digital certificate from the issuing 
authority to the customer, the signed digital certificate 
comprising part of the commerce card. 

15. A method as recited in claim 14, wherein the supply- 
ing step comprises the step of providing the preUminary 
customer identifier to the customer through means other than 
online transmission, 

16. A method as recited in claim 14, wherein the step of 
submitting the request for a certificate comprises the fol- 
lowing steps: 

composing a public key; 

generating a private key that is associated with the public 
key; and 

submitting a request for certificate that includes the public 
and private keys. 

17. A method as recited in claim 16, further comprising 
the step of using the signed digital certificate and the private 
key as a password for communication between the customer 
and issuing authority. 

18. A method as recited in claim 14, further comprising 
downloading to the customer software code that supports a 
user interface button to invoke a user interface for facilitat- 
ing commerce transactions. 

19. A graphical user interface embodied on a computer- 
readable medium that presents the user interface button as 
recited in claim 18. 

20. Computer-readable media resident at the customer 
and the issuing authority having computer-executable 
instructions for performing the steps in the method as recited 
in claim 14. 

21. A method for utilizing an online commerce card in 
conducting online commerce transactions between a cus- 
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tomer and a merchant, the conmierce card having a perma- 
nent customer number associated therewith to identify the 
customer, comprising the following steps: 
submitting a request for a proxy number from the cus- 
5 tomer to an authority; 

generating the proxy number at the authority; 
associating the proxy number with the permanent cus- 
tomer number; 
issuing the proxy number to the customer; and 
10 sending the proxy number, rather than the permanent 
customer number, to the merchant to commence the 
online commerce transaction. 

22. A method as recited in claim 21, further comprising 
the following steps: 

15 generating a request that comprises a password unique to 
the customer; 
digitally signing the request at the customer; 
submitting the digitally signed request from the customer 
to the authority; and 
^ authenticating the customer from the digitally signed 
request. 

23. A method as recited in claim 21, further comprising 
the step of displaying the proxy number returned from the 
authority. 

24. Computer-readable media resident at the customer 
and the authority having computer-executable instructions 
for performing the steps in the method as recited in claim 21. 

25. A computer-implemented method for handling a 
request for an online commerce transaction nimiber that can 
be used by a customer in conducting an online commerce 
transaction, comprising the following steps: 

generating a transaction number; 
associating the transaction number with a customer num- 
35 bcr that identifies the customer; and 

transmitting the transaction number to the customer for 

use as a proxy for the customer number during the 

online commerce transaction. 

26. A computer-implemented method as recited in claim 
40 25, wherein the associating step comprises the step of 

creating a record in a database, the record linking the 
transaction number to the customer number. 

27. A computer-implemented method as recited in claim 
25, further comprising the step of assigning an expiration 

45 time to the transaction number that specifies when the 
transaction number expires. 

28. A computer-readable medium having computer- 
executable instructions for performing the steps in the 
computer-implemented method as recited in claim 25. 

50 29. A computer programmed to perform the steps in the 
computer-implemented method as recited in claim 25. 

30. At an authority responsible for authorizing an online 
commerce transaction involving payment by an elecu-oni- 
cally transmitted account number, a computer- implemented 

55 method for handling an authorization request to honor the 
account number and accept payment, comprising the fol- 
lowing steps: 

determining whether the authorization request involves a 
permanent customer account number or a transaction 
60 number that is used as a proxy for the customer account 
number, 

in an event that the authorization request involves a 
transaction number, performing the following steps: 
using the transaction number to cross-reference to an 
65 associated customer account number; 

substituting the associated customer account number in 
place of the transaction number; and 
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processing the authorization request using the associ- 
ated customer account number. 

31. A computer-implemented method as recited in claim 
30, further comprising the step of accessing a database 
containing customer account numbers and using the trans- 5 
action number as an index to the database for locating the 
associated customer account number. 

32. A computer- implemented method as recited in claim 
30, wherein after the processing step, the method further 
comprising the following steps: lo 

substituting the transaction number in place of the cus- 
tomer account number; and 

replying to the authorization request using the transaction 
number in lieu of the customer account number. 

33. A computer- implemented method as recited in claim 
30, further comprising the step of adjusting an account 
associated with the customer account number to reflect the 
payment made in the online commerce transaction. 

34. A computer-readable medium having computer- 
executable instructions for performing the steps in the 
computer-implemented method as recited in claim 30. 

35. A computer programmed to perform the steps in the 
computer-implemented method as recited in claim 30. 

36. A method for facilitating online commerce, compris- 
ing the following steps: 

(A) conducting a registration phase between a customer 
and an issuing authority comprising the following 
steps: 

(1) initialing, at the customer, a request for an online 
commerce card application; 

(2) downloading software code lo the customer to assist 
in completing the card application; 

(3) submitting the application for the commerce card 
from the customer to the issuing authority; 

(4) supplying a preliminary customer identifier lo the 
customer; 

(5) submitting, from the customer, a request for a 
certificate from the issuing authority, the request 
including the preliminary customer identifier to iden- 
tify the customer; and 

(6) associating a customer account number with the 
customer; and 

(7) downloading a signed digital certificate from the 
issuing authority to the customer and software code 
that supports a user interface button to invoke a user 
interface for facilitating online commerce 
transactions, the signed digital certificate and user 
interface button forming the online commerce card 
having the customer account number associated 
therewith; 

(B) utilizing the online commerce card to conduct an 
online commerce transaction phase between the cus- 
tomer and a merchant comprising the following steps: 

(1) submitting a request to use the commerce card firom 55 
the customer to the issuing authority; 

(2) generating a transaction number; 

(3) associating the transaction number with the cus- 
tomer account number, and 

(4) transmitting the transaction number to the customer 50 
for use as a proxy for the customer account number 
during the online commerce transaction; 

(5) sending the transaction number, rather than the 
permanent customer number, to the merchant lo 
commence the online commerce transaction; 55 

(C) conducting a payment authorization phase at the 
issuing authority in response to receiving an authori- 



zation request from the merchant to honor the transac- 
tion number and accept payment, comprising the fol- 
lowing steps: 

(1) identifying the authorization request as involving a 
transaaion number that is used as a proxy for the 
customer account number; 

(2) using the transaction number to cross-reference lo 
the associated customer account number; 

(3) substituting the associated customer account num- 
ber in place of the transaction number; 

(4) processing the authorization request using the asso- 
ciated customer account number; 

(5) substimting the transaction number in place of the 
customer account number; and 

(6) replying to the merchant using the transaction 
number in lieu of the customer account number. 

37. A system for facilitating online commerce, compris- 
ing: 

a customer computing unit resident at a customer site, the 
customer computing unit being configured with an 
online commerce card for use in online commerce 
transactions, the online commerce card being associ- 
ated with a customer account number; 

an authority computing system resident at an authority 
site, the authority computing system having a database 
to hold the customer account number, the authority 
computing system being configured to generate a trans- 
action number, associate the transaction number with 
the customer account number in the database and 
electronically issue the transaction number to the cus- 
tomer computing unit; 

the customer computing unit being configured lo use the 
transaction number in an onhne commerce transaction 
with a merchant; and 

the authority computing system being configured to 
receive from the merchant an authorization request for 
approval of the transaction number, the authority com- 
puting system using the transaction number to cross- 
reference in the database the associated customer 
account number and lo process the authorization 
request with the customer account number 

38. A system as recited in claim 37, wherein the customer 
account and transaction numbers are formatted with an equal 
number of digits. 

39. A system as recited in claim 37, wherein the authority 
computing system assigns an expiration term lo the trans- 
action number so ihat ihe transaction number is not vahd 
after the expiration term elapses. 

40. A system for issuing online commerce cards used in 
online commerce transactions, comprising: 

a customer account manager to establish a customer 
account number for a customer and to associate the 
customer account number to a digital certificate that is 
unique to the customer, the digital certificate being in 
embodied in an electronically transmitlable form which 
can be downloaded to the customer for use as an online 
commerce card; 

a transaction number generator to generate a transaction 
number for an online commerce transaction in which 
the customer desires to engage; and 

the customer account manager being configured to asso- 
ciate the transaction number with the customer account 
number, the u-ansaction number being embodied in an 
electronically transmitlable form which can be down- 
loaded lo the customer so that the customer can use the 
transaction number in the online commerce transaction 
as a proxy for the customer account number. 
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41. A software program embodied on a computer- readable 
medium incorporating the system as recited in claim 40. 

42. In an online commerce system, a system for handling 
an authorization request to approve an electronically trans- 
mittable number, comprising: 5 

a transaction number identifier to identify the number as 
a transaction number that is used as a proxy for a 
customer account number; and 

a customer account manager to cross-reference the cus- 
tomer account number using the transaction number *° 
and to substitute the transaction nimnber for the cus- 
tomer account number for further processing. 

43. A system as recited in claim 42, wherein the customer 
account manager is configured to reverse substitute the 
transaction number back for the customer account number 
after the processing. 

44. A software program embodied on a computer- re ad able 
medium incorporating the system as recited in claim 42. 
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45. An electronically realizable commerce card embodied 
on a computer-readable medium comprising: 

a first data field to hold a permanent customer account 
number having N digits and a predefined format that is 
recognized as an acceptable card number format; 

a second data field to hold a temporary transaction num- 
ber that serves as a proxy for the customer account 
number, the transaction number having the N digits and 
the format identical to the customer account number; 
and 

wherein the first and second data fields are related to 
associate the customer account number with ibe trans- 
action number. 
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